chore: update roles with interactive info #2517
Conversation
| <div class="foo" id="foo">foo</div> | ||
| <div role="button"> | ||
| Hello | ||
| <div role="button">Goodbye</div> | ||
| </div> |
There was a problem hiding this comment.
I'm guessing you didn't mean to put this in?
| - `heading` | ||
| - `phrasing` | ||
| - `interactive` | ||
| - `interactiveDescendant` - boolean(optional. Default `true`). If the role is allowed to have interactive descendants. |
There was a problem hiding this comment.
If this is exclusively based on whether contentType includes "interactive", this is redundant. I'm not sure this is the right solution though. What I was thinking is to look at ARIA's "presentational children" property. The issue isn't that screen readers just don't know how to deal with nested interactive elements. It's that anything you put inside of an element with presentational children will not be included in the accessibility tree. Not just interactive stuff either:
The image in this button is not in the accessibility tree. This button wouldn't be announced as having an image inside it. But if you put role=link on the button, it will be.
<button><img src="..." alt="hello" /></button>
There are interactive elements that require other interactive children. Combobox and listbox jump to mine. I suspect you can also do it with links without causing accessibility problems. ARIA definitely says you can, but we should probably test that to be sure.
|
Closing per Wilcos comment (making a new PR with presentational children instead) |
The information was taken from https://www.w3.org/TR/html-aria/#allowed-aria-roles-states-and-properties
This is a precursor to #601. From reading the discussion in that issue, there was a lot of concern with false positives of nested roles. For example, a
menuitemcannot have interactive descendants but is allowed amenuwhich could have amenuitem.To address that, I believe the following algorithm works in all listed cases of that pr:
interactiveDescendant: false. An interactive role is defined as a role whosecontentTypesincludesinteractive(this step can be done in a rule matcher)contentTypesincludesflow, continue to the next descendantcontentTypesalso includesinteractivethen don't loop through its descendants as the algorithm will start again from that descendantcontentTypesincludesinteractiveit failsThis should catch all the issues brought up in the original issue, allowing
menuitemsto havemenuchildren as it is both flow and interactive (causing the algorithm to break and start again from there). It should also catch ARIA buttons having nested HTML interactive elements such as anchors or buttons.Reviewer checks
Required fields, to be filled out by PR reviewer(s)